BigIntegerValidator's minValue(Number, Number) and maxValue(Number, Number) compare the operands as BigDecimal, but unlike the equivalent BigDecimalValidator overloads they never guard for a non-finite bound. A Double.NaN, POSITIVE_INFINITY or NEGATIVE_INFINITY argument is routed straight into BigDecimal.valueOf(double), which cannot represent those values and throws NumberFormatException, so the call (and the inherited isInRange that delegates to it) blows up with an undeclared exception rather than returning a boolean. I traced this from an open-ended range check where an infinite upper bound threw instead of accepting every finite value; BigDecimalValidator accepts the same bound without complaint, so the two validators disagree.

The fix guards both overrides with isFinite and falls back to the doubleValue() comparison when either operand is non-finite, mirroring BigDecimalValidator. The finite path is untouched, so the exact-magnitude and fractional-bound behaviour stays as it was; only the previously-throwing case changes, with a NaN bound never satisfied and an infinity treated as an open bound. Keeping the guard in the callee means every entry point stays consistent without callers having to sanitise their bounds first.